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[57] ABSTRACT 

Packets transported over a serial data stream need to 
have their start and stop information encoded so that 
they can be parsed by the receiving device. Techniques 
used in various standards require extra bandwidth to 
carry this information. For framed data streams like Tl, 
proprietary protocols have used the frame structure to 
mark packet boundaries. Both types of solutions are 
undesirable for unframed, long distance data streams 
like the CCITT G.703 2.048 Mbps unframed service, 
subrate trunks, or fractional Tl services. The present 
invention provides a packet framing method that uses 
the Cyclic Redundancy Check (CRC) found in most 
packet formats. The protocol does not require any extra 
bandwidth and can work with any serial data stream 
physical layer. 

2 Claims, 5 Drawing Sheets 
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PACKET FRAMING USING CYCLIC 
REDUNDANCY CHECKING 

This is a continuation-in-part of application Ser. No. 
454,258 filed Dec. 21, 1989 now abandoned. 

BACKGROUND OF THE INVENTION 

The present invention relates to a data communica- 
tions system and method utilizing packet framing tech- 
niques. 

Serial data streams that use packet protocols to trans- 
fer information need to establish byte alignment of the 
data and mark the beginning and end of the packets. 

In the past various methods have been used to accom- 
plish these tasks. HDLC (High-level Data Line Con- 
trol) protocols use a unique eight bit flag to mark a 
packet's start and end. Inside the packet the data is bit 
stuffed to prevent an accidental flag from being sent. 
The 802.3 "Ethernet" standard is typical of another set 
of protocols which use an idle preamble followed by a 
nan-idle packet start header to mark the beginning of a 
packet. 

These methods have worked well in applications 
where bandwidth efficiency has not been an issue. 
However in telecommunications, the customer typi- 
cally rents bandwidth from a service provider. Proto- 
cols for this application have to maximize the band- 
width available for the customer's data to save money 
on the purchased service. The framing algorithm should 
have as low an overhead as possible. For example if 24 
bytes of user data were carried in an HDLC framed 
packet, it could have as much as 27 bits of data stuffed 
into it to prevent a false flag. 

To this would be added a start and end flag of eight 
bits each. Such a worst case packet would have a 22% 
packet framing overhead. For a Tl line which can cost 
hundreds or thousands of dollars a month, this is expen- 
sive. 

StrataCom, Inc. manufactures a digital multiplexer 
(known as the Integrated Packet Exchange (IPX)) that 
connects customer's voice and data equipment together 
over Tl lines using a packet transport protocol. That 
IPX multiplier is described in U.S. Pat. No. 4,771,425, 
the details of which are hereby incorporated by refer- 
ence. 

Presently the IPX solves the problem of framing 
packets on Tl lines by making all of its packets 24 bytes 
long and placing them inside a Tl frame. The Tl frame 
format has one framing bit and 24 bytes of data; 193 bits 
total. The Tl framing bit is required for the line to use Tl 
vendor services. Therefore, this packet framing, which 
is the same as the Tl line framing, needs no extra band- 
width. 

This solution does not work with other types of trunk 
interfaces and for packets that are not 24 bytes long. 
Fractional Tl and framed El (El is the 2.048 Mbps trunk 
defined by CCITT G.703 standard) can supply byte 
alignment but do not have 24 bytes per frame for the 
packet alignment needed by the IPX packet protocol. 
Unframed El (Britin's Mega-Stream), V.1I (Britain's 
Kilo-Stream and France's Transfix) and V.35 sub-rate 
trunks do not have either byte or packet alignment 
signals in their physical interface. 



SUMMARY OF THE INVENTION 

It is an object of the present invention to provide an 
improved data communications system and method 
5 utilizing packet framing techniques. 

It is a more particular object of the present invention 
to provide packet framing using cyclic redundancy 
checking. 

The CRC packet framing algorithm described below 
10 is a protocol that byte aligns and packet frames a serial 
bit stream, from the existing data structure in common 
packet formats. It achieves packet framing without 
additional bandwidth overhead. 
A solution to the packet framing problem must use as 
15 little bandwidth as possible, be transparent to the user's 
data, accommodate high packet throughput rate, and be 
robust. By robust, it is meant that the algorithm must be 
fast in recovering from errors, it must achieve quick 
packet alignment (Tl synchronization times of 10 msec 
20 are acceptable), and it should have low error multiplica- 
tion (a transmission error affecting the framing algo- 
rithm should not cause a large amount of data to be 
lost). 

Other objects, features and advantages of the present 
25 invention will become apparent from the following 
detailed description when taken in conjunction with the 
accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

30 The accompanying drawings which are incorporated 
in and form a part of this specification illustrate an em- 
bodiment of the invention and, together with the de- 
scription, serve to explain the principles of the inven- 
tion. 

35 FIG. 1 depicts an IPX packet format for describing 
the operation of the present invention. 

FIG. 2 depicts a framing algorithm state machine for 
describing the operation of the present invention. 

FIG. 3 depicts a table illustrating packet framing time 
40 for trunks without byte alignment. 

FIG. 4 depicts a table showing packet framing times 
for trunks with byte alignment. 

FIG. 5 depicts a table illustrating deframer processor 
utilization. 

45 FIG. 6 depicts a table illustrating framer processor 
utilization. 

FIG. 7 depicts deframer architecture utilized with the 
present invention. 
FIG. 8 depicts framer architecture utilized with the 
50 present invention. 

DETAILED DESCRIPTION OF THE 
DRAWINGS 

Reference will now be made in detail to the preferred 
55 embodiment of the invention, an example of which is' 
illustrated in the accompanying drawings. While the 
invention will be described in conjunction with the 
preferred embodiment, it will be understood that it is 
not intended to limit the invention to that embodiment. 
60 On the contrary, it is intended to cover alternatives, 
modifications and equivalents as may be included 
within the spirit and scope of the invention as defined 
by the appended claims. 

65 PROTOCOL DESCRIPTION 

The CRC packet framing technique can be applied to 
any packet format that has an error checking code em- 
bedded in it Described here is the way packet framing 
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is achieved using one preferred packet format with its thirty two of finding a good CRC in jandom data. The 

CRC code. "Verify" state requires four packets in a row be framed 

Referring now to FIG. I, the IPX packet format is a by five good CRCs to frame synchronize the line. For 

fixed 24 byte packet that contains either a three or four . random data the probability of a fake frame is 3MO~ 8 . 

byte header depending on the packet type, see FIG. 1. 5 No packets are accepted by the receiver state machine 

The first two bytes (Bytes 1 and 2) are the packers in the "Verify" state. 

destination address. The third byte contains a three bit Packet boundaries used to calculate CRCs in the 

packet type identification number and a five bit Cyclic "Verify", •'Monitor", and "Error" states are deter- 

Redundancy types of packets; it contains a time stamp. mined by the packet length. Normal IPX packets have 

The CRC is calculated over the first four bytes of the 10 a fixed, 24 byte length. A special four byte long "Idle 

packet regardless of whether the packet type has a time Trunk Packet" is used between IPX nodes when no user 

stamp byte or not. data packets are available to send. The "Idle" packet's 

A framing algorithm state machine is shown in FIG. shorter length helps speed the packet framing processes. 

2. The CRC framing algorithm, has four states. The A special IPX packet address (see FIG. 1) is used to 

machine initializes itself in the "Search" state. The 15 identify the "Idle" packet. 

"Search" state looks for a good CRC in the serial bit When a good CRC sequence is found in the "Verify" 

stream. When a good CRC is found the algorithm enters state the line is considered to be synchronized to both 

a "Verify" state where it checks consecutive packets for the data stream's byte boundary and to the packet 

.good CRC to make sure that the packet frame boundary frame. The framing algorithm then goes to the "Moni- 

has been found. If there is a bad CRC in the ''Verify" 20 tor" state and packet reception starts, 

state, the algorithm returns to the "Search" state. If in the "Monitor" state a bad CRC is found, caused 

In the "Verify" state a packet is good if its CRC and by either a transmission error or a loss of synchroniza- 

the CRC of the next packet are correct. If the verifica- tion, then the "Error" state in entered. The "Error" 

tion is successful then the "Monitor" state is entered. In state checks the packet framing synchronization with- 

this state the algorithm enables the receiver to store 25 out throwing out good packets or shifting the frame 

packets and it continues to check the received packet's byte boundary. This prevents a simple line error from 

CRC. If a bad CRC is found the algorithm goes to an affecting more than one packet (error multiplication). 

"Error" state. In the "Error" state, good packets con- For the IPX, desynchronization is not started until forty 

tinue to be received and the CRC checked. A packet eight bytes of data are checked and no good, CRC 

framed by good CRCs immediately returns the algo- 30 framed packet is found. 

rithm to "Monitor" state; consecutive bad CRC checks A pseudo code implementation of the IPX algorithm 

puts the algorithm in the "Search" state is given in Appendix A. 

In the •'Search" state the CRC framing algorithm The algorithm is flexible. It can be applied to more 

looks at the serial bit stream for bit sequences that have than the IPX packet protocol. The CRC can be differ- 

a valid check sum. In the case of the IPX format, the 35 ent sizes (ie. CRC(8), CRC(i6)>, the CRC can cover 

algorithm looks for a valid CRC(5) over a 32 bit span of some or all of a packet; and the packets can have a 

data. variable length. For variable length packets, the length 

The specific IPX framing implementation is executed field can be read to know where the next packet should 

by a micro processor and a hardware receive buffer that start. 

can be bit aligned. The framing architecture is shown in 40 If the trunk has its own byte framing built in like Tl or 

FIG. 8 and the deframer architecture is shown in FIG. framed El, the CRC framing algorithm saves time by 

7. only doing byte shifts of the data stream to find the 

The buffer is one byte wide and it receives data di- packet boundaries. 

recti y from the line interface chips. The processor can „ _ _ . „ % , 

control the bit aligr^ent within the byte £ the data put 45 CRC PACKET FRAMWG PERFORMANCE FOR 

into the bufTer by the interface. The framing algorithm THE IPX 

is optimized so that the processor's real time require- Bandwidth: 

ments in the search phase are kept low. No extra bandwidth required; the framing is done 

This is done by having the processor scan a window with the existing packet's CRC. 

of 32 bits from the hardware buffer for good CRC and 50 CRC (5) Characteristics: 

then discarding the data if the check fails. The proces- The CRC(5) used by the IPX is five bits long, covers 
sor is freed from the bit manipulations of data that 32 bits (including itself), and uses the polynomial: 
would be required if it were to look for all the possible X 5 +X 4 +X 3 +X 2 +X°=61 (decimal- 
patterns within a window of data. The time required to The error coverage for 32 bits is: 
find a packet frame boundary is increased because data 55 100% of single bit errors, 
is discarded, but doing so makes the real time require- 97% of double bit errors, 
ments of the processor easier to estimate and engineer. 100% of bursts less than 5 bits long. 
On a given byte boundary, the processor checks six 97% of random data patterns, 
windows of 32 bits each for two good CRCs framing a Time to Frame a Line: 

packet. If no match is found, the processor shifts the bit 60 The time to packet frame a line depends on the data 

alignment of the hardware buffer. The CRC is then rate of the line, whether the line's data is byte aligned or 

checked over another six windows (24 bytes) of data. not, the nature of the data pattern on the line, and how 

The algorithm continues bit shifting until a good CRC is many "Idle" packets are being sent 

found. Two good CRCs framing a packet changes the Four types of times are calculated; worst case busy, 

algorithm's state from "Search" to "Verify". 65 worst case idle, typical busy, and typical idle. 

The "Verify" mode is used to insure that an acciden- The "Worst Case" times assume the worst bit and 

tal CRC match is not used to frame the packet line. For byte alignment requiring the most shifts and searches, 

the IPX the CRC(5) has a probability of one chance in They also assume that all the data is random. The num- 
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ber of false CRC's seen is one standard deviation greater 
than the mean expected number. The worst case proba- 
bilities in Table 1 are 0.2%, in Table 2 they are 2%. 

The "Typical Case" times use average numbers for 
the number of bit and byte shifts and for the number of 5 
false CRCs. 

All the Tl and El trunk packet framing times compare 
favorably with Tl line framing times in the 10 msec 
range. 

Error Multiplication: 10 
When an error is detected in the "Monitor" state, the 
IPX packet receiver drops that packet and goes to the 
"Error" state- Good CRC packets in the "Error" state 
are transmitted on the IPX bus. For a bit error in the 
packet header, error multiplication is limited to loosing 15 
one packet of up to 21 bytes of customer data. This is 
the same error multiplication as in the current IPX 
product without CRC packet framing. 



packets on parallel bus 62. Frame p/ocessor 66 pro- 
cesses 2x 10 7 instructions per second. 

The output of framer processor 66 is via 8-bit bus 70 
to 32-byte buffer memory 74. 

The output of memory 74 is via 8-bit bus 78 to a 
buffer manager 80 which includes a read/write address 
counter and parallel to serial converter. 

Framer processor provides a write* byte request signal 
on lead 76 to buffer manager 80. Framer processor 
receives instructions from program memory 68 contain- 
ing control algorithms for a cyclic redundancy check 
according to the present invention. 

The output of buffer manager 80 is a serial data 
stream on lead 84 which is connected to physical line 
transmitter circuit 88 for output as a serial data stream 
to trunk 90. 

The foregoing description of the preferred embodi- 
ment of the invention has been presented for purposes 
of illustration and description. It is not intended to be 



Robustness: 

The packet framing algorithm is inherently robust. 20 exhaustive or to limit the invention to the precise form 

The "Verify" state checks that the line has not falsely disclosed, and many modifications and variations are 

framed to an erroneous packet boundary. The probabil- possible in light of the above teaching. For example, 

ity of a false frame is 3x 10- 8 . Even if a line were to error detection information in general could be utilized 

falsely frame, the "Monitor" state constantly checks for with the present invention. The preferred embodiment 

loss of packet frame synchronization. In such a circum- 25 utilizing cyclic redundancy checking was chosen and 



30 



described in order to best explain the principles of the 
invention and its practical applications to thereby en- 
able others skilled in the art to best utilize the invention 
and various embodiments and with various modifica- 
tions as are suited to the particular use contemplated. It 
is intended that the scope of the invention be defined 
only by the claims appended hereto. 



35 Appendix A: The IPX Pseudo Code Packet Framing Algorithm 
DEFRAMER ( ) 
{ 

STATE = SEARCH; /* INITIAL CONDITION V 
IF (LINE - Tl OR El — 31 —CHANNEL OR 
E1_30_CHANNEL OR 

FRAC_T1 THEN SET LINE—TYPE = FRAMED); 
ELSE (LINE-TYPE = UNFRAMED); 
WHILE (NON-STOP) 
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stance the "Error'* state would re-initiate the packet 
frame search. 
Packet Throughput: 

The IPX Network Trunk Card (NTC) implements 
the CRC packet framing algorithm with two proces- 
sors; a Framer (transmit to the line) and a Deframer 
{receive from the line). The real time required for each 
processor has been estimated for their complete set of 
tasks which include functions in addition to CRC fram- 
ing and deframing. The numbers in Tables 3 and 4 are 
worst case averages of processor utilization based on 
simulations of the code and data. Each processor has 
2500 instruction cycles available to it in a 125 micro- 
second period. 

Data Transparency: 

The CRC packet framing algorithm places no con- 
straints on the user's data. False CRC matches within 
the data do not permanently keep the algorithm from 
finding the correct packet frame alignment. 

Referring now to FIG. 7, deframer architecture 10 45 
according to the present invention is shown, in which 
serial data stream via trunk 12 is input to a physical line 
receiver interface circuit 14. The output of circuit is a 
serial data stream on bus 16 which is input to a buffer 
manager 20. 

Buffer manager 20 includes a read/write address 
counter and serial to parallel converter for outputting 
8-bit data on bus 22 to 32-byte buffer memory 24. search f ) 

The output of memory 24 on 8-bit bus 26 is input to a ^ K} 
deframer processor 30 which processes 2xl0 7 instruc- 55 search_status = NOT-FOUND; 
tions per second. while (search-Status « not_found) 

The deframer processor X I provides a shift bit align- ( qr yjwckt _ BYTECNT < 4* 

ment signal on lead 36 to buffer manager 20. Also, de- 
framer processor 30 provides a read/write request sig- 
nal on lead to buffer manager 20. 

Deframer processor 30 receives control information 
from a program memory 34. The control information 
contains an algorithm for framing the trunks. The out- 
put of deframer processor 30 is 8-bit bus 40 carrying 
user data packets. 

FIG. 8 depicts a framer architecture 60 according to 
the present invention. In FIG. 8, the framer architecture 
includes a frame processor 66 which receives user data 



{ 

SWITCH (STATE) 
{ 

CASE SEARCH: 
CASE VERIFY: 
CASE MONITOR: 



50 



CASE ERROR; 



SEARCH ( ); 
BREAK; 
VERIFY ( y, 
BREAK; 
MONITOR (); 
BREAK; 
ERROR ( ); 
BREAK; 



} 



60 



65 



BYTECNT BYTECNT + 4) 
{ 

IF (NEXT FOUR BYTES HAVE A GOOD CRC AND 
THE NEXT PACKET IS FOLLOWED BY A 
GOOD CRC) 
{ 

SEARCH-STATUS = FOUND; 
STATE = VERIFY; 
) 

} 

IF (LINE-TYPE = UNFRAMED) SHIFT HARDWARE 
BUFFER ONE BIT ( ); 

> 
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Appendix A: The IPX Fseudo Code Packet Framing Algorithm 

} 

VERIFY () 
{ 

V ER I FY_ST ATU S = NOT VERIFIED; 
WHILE (VERIFY—STATUS = NOT_ VERIFIED) 
{ 

FOR (CRC_CNT «= 0; CRC_CNT < 4; 
CRC_CNT=CRC_CNT+4) 
{ 

IF (BAD CRC ON NEXT EXPECTED PACKET 
BOUNDARY) 
{ 

STATE = SEARCH; 

BREAK; 

} 

} 

VERIFY—STATUS = VERIFIED; 
/• FOUR GOOD PACKETS •/ 
} 

IF (STATE = SEARCH) STATE = MONITOR; 
} 

MONITOR ( ) 
{ 

MONITOR-STATUS = CRC-OK; 
WHILE (MONITOR—STATUS _ CRC-OK) 
{ 

IF (GOOD CRC ON NEXT EXPECTED PKT 
BOUNDARY) 
{ 

IF (LAST PACKET WAS 24 BYTES) 
WRITE LAST PACKET TO MUXBUS ( ); 

} 

ELSE /• BAD CRC V 
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IS 



{ 

MONITOR—STATUS = CRC— BAD; 

STATE = ERROR; 

} 

} 

} 

ERROR ( ) 
{ 

FOR (BYTE— CNT « 0, BYTE— C NT < 48; 
BYTE— CNT= BYTE— C NT +4) 
{ 

IF (NEXT 4 BYTES HAVE GOOD CRC) 
{ 

IF THIS IS AN EXPECTED BOUNDARY OF EITHER 
A 4 OR 24 BYTE PACKET, WHOSE START WAS 
FOUND IN THE MONITOR STATE OR THIS IS A 
GOOD CRC FOUND IN THIS THE ERROR STATE 
THEN 
{ 



STATE = MONITOR; 
} 



/* END OF FRAME SYNC V 



STATE «= SEARCH; 
> 
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What is claimed is: 

1. In a data communication system, a packet bound- 
ary detection method comprising the steps of 



transmitting to a destination address a serial bit data 
stream containing packet information including a 
multi-byte header having a packet destination ad- 
dress and error detection information, said error 
detection information being a multi-bit cyclic re- 
dundancy check (CRC) sum, 

detecting said packet boundary including decoding 
said packet information at said destination address 
based upon said error detection information, 

transmitting to a destination address a serial bit data 
stream containing packet information including a 
multi-byte header having a packet destination ad- 
dress and a multi-bit cyclic redundancy check 
(CRC) sum, 

initially searching said serial bit stream in a search 
mode for a good or verifiable CRC, 

verifying in a verify mode said verifiable CRC, 

monitoring in a monitor mode said CRC sum for an 
error, including continuously checking CRC re- 
ceived packets containing received CRC data, 

entering an error mode if a bad CRC is found, includ- 
ing continuously checking said CRC sum for good 
packets, 

returning to said monitoring mode if good CRCs are 
received, and 

returning to said searching mode if consecutive bad 
CRCs are found. . 

2. In a data communication system, packet boundary 
detection apparatus comprising 

means for transmitting to a destination address a serial 
bit data stream containing packet information in- 
cluding a multi-byte header having a packet desti- 
nation address and error detection information, 
said error detection information being a multi-bit 
cyclic redundancy check (CRC) sum, 

packet boundary detection means including means 
for decoding said packet information at said desti- 
nation address based upon said error detection 
information, 

means for initially searching said serial bit stream in a 
search mode for a good or verifiable CRC, 

means for verifying in a verify mode said verifiable 
CRC, 

means for monitoring in a monitor mode said CRC 
sum for an error, including continuously checking 
received CRC packets containing received CRC 
data, 

means of entering an error mode if a bad CRC is 
found, including continuously checking said CRC 
sum for good packets, 

means for returning to said monitoring mode if good 
CRCs are received, and 

means for returning to said searching mode if consec- 
utive bad CRCs are found. 
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